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Abstract 

Predictability  -  the  ability  to  foretell  that  an  implementation  will  not  violate  a 
set  of  specified  reliability  and  timeliness  requirements  -  is  a  crucial,  highly  desirable 
property  of  responsive  embedded  systems.  This  paper  overviews  a  development 
methodology  for  responsive  systems,  which  enhances  predictability  by  eliminating 
potential  hazards  resulting  from  physically-unsound  specifications. 

The  backbone  of  our  methodology  is  the  Time-constrained  Reactive  Automaton 
(TRA)  formalism,  which  adopts  a  fundamental  notion  of  space  and  time  that  restricts 
expressiveness  in  a  way  that  allows  the  specification  of  only  reactive,  spontaneous, 
and  causal  computation.  Using  the  TRA  model,  unrealistic  systems  -  possessing 
properties  such  as  clairvoyance,  caprice,  infinite  capacity,  or  perfect  timing  -  cannot 
even  be  specified.  We  argue  that  this  “ounce  of  prevention”  at  the  specification  level 
is  likely  to  spare  a  lot  of  time  and  energy  in  the  development  cycle  of  responsive 
systems  -  not  to  mention  the  elimination  of  potential  hazards  that  would  have  gone, 
otherwise,  unnoticed. 

The  TRA  model  is  presented  to  system  developers  through  the  CCEOVATJIA 
programming  language.  CC£OVATHA  features  a  C-like  imperative  syntax  for  the 
description  of  computation,  which  makes  it  easier  to  incorporate  in  applications  al¬ 
ready  using  C.  It  is  event-driven,  and  thus  appropriate  for  embedded  process  control 
applications.  It  is  object-oriented  and  compositional,  thus  advocating  modularity 
and  reusability.  CCEOVATRA  is  semantically  sound;  its  objects  can  be  transformed, 
mechanically  and  unambiguously,  into  formal  TRA  automata  for  verification  pur¬ 
poses,  which  can  be  pursued  using  model-checking  or  theorem  proving  techniques. 
Since  1989,  an  ancestor  of  CCEOVATRA  has  been  in  use  as  a  specification  and  sim¬ 
ulation  language  for  embedded  time-critical  robotic  processes. 


‘This  research  was  partially  conducted  while  the  author  was  at  Harvard  University  and  was  partially  supported 
by  DARPA  N00039-88-C-0163 . 
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1  Introduction 


A  computing  system  is  embedded  if  it  is  a  component  of  a  larger  system  whose  primary  purpose 
is  to  monitor  and  control  an  environment.  The  leaping  advances  in  computing  technologies  that 
the  last  few  decades  have  witnessed  have  resulted  in  an  explosion  in  the  extent  and  variety  of  such 
systems.  This  trend  is  expected  to  continue  in  the  future. 

Embedded  systems  are  usually  associated  with  critical  applications,  in  which  human  lives 
or  expensive  machinery  are  at  stake.  Their  missions  are  often  long-lived  and  uninterruptible, 
making  maintenance  or  reconfiguration  difficult.  Examples  include  command  and  control  sys¬ 
tems,  nuclear  reactors,  process-control  plants,  robotics,  avionics,  switching  circuits  and  telephony, 
data- acquisition  systems,  and  real-time  databases,  just  to  name  a  few.  The  sustained  demands 
of  the  environments  in  which  such  systems  operate  pose  relatively  rigid  and  urgent  performance 
requirements.  These  requirements  are  usually  stated  as  timing  constraints  on  their  behaviors. 
Wirth  [Wirt77]  singled  out  this  processing-time  dependency  as  the  one  aspect  that  differentiates 
real-time  from  other  sequential  and  parallel  systems.  This  led  to  a  body  of  research  on  real¬ 
time  computing ,  which  encompasses  issues  of  specification  techniques,  validation  and  prototyp¬ 
ing,  formal  verification,  safety  analysis,  programming  languages,  development  tools,  scheduling, 
and  operating  systems.  In  addition  to  timeliness,  embedded  systems  are  also  required  to  meet 
stringent  reliability  constraints,  which  are  usually  stated  as  behavioral  safety  and  liveness  invari¬ 
ants.  For  comprehensive  surveys  of  recent  research  in  real-time  systems,  the  reader  is  directed  to 
[Stan88b,  Burn90,  Tilb91a,  Tilb91b]. 

The  absence  of  a  unified  suitable  formal  framework  that  addresses  the  aforementioned  issues 
severely  limits  the  usefulness  of  these  studies.  This  situation  is  further  exacerbated  considering 
the  range  of  disciplines  employed  in  developing  the  various  components  of  an  embedded  applica¬ 
tion.  For  example,  in  a  simple  sensori-motor  robotic  application  [Clar91],  algorithms  from  various 
disciplines  like  low-level  imaging,  active  vision,  tactile  sensing,  path  planning,  compliant  motion 
control,  and  non-linear  dynamics  may  be  utilized  [Fu87].  Not  only  are  these  disciplines  different 
in  their  abstractions  and  programming  styles,  but  also  they  differ  in  their  computational  require¬ 
ments,  which  range  from  single-board  dedicated  processors  to  massively  parallel  general-purpose 
computers. 

Current  embedded  systems  are  expensive  to  build  and  their  properties  are  verified  with  ad 
hoc  techniques[Stan88a].  Schneider  [Schn88]  portrays  the  situation  aptly  by  saying  that  “Unlike 
other  engineering  disciplines,  our  methods  are  not  founded  on  science.  Real-time  systems  are  built 
one  way  or  another  because  that  was  the  way  the  ‘last  one’  was  built.  And,  since  the  ‘last  one’ 
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worked,  we  hope  that  the  next  one  will”.  This  brute  force  approach  is  not  likely  to  scale-up  with 
future  systems. 

In  this  paper  we  propose  CLEOPATRA,1  a  programming  environment  that  recognizes  the 
unique  requirements  of  responsive  embedded  systems.  CLEOPATRA  features  a  C-like  imperative  syn¬ 
tax  for  the  description  of  computation,  which  makes  it  easier  to  incorporate  in  applications  already 
using  C.  It  is  event-driven,  and  thus  appropriate  for  embedded  process  control  applications.  In  par¬ 
ticular,  rather  than  describing  behaviors  using  control  structures,  it  describes  behaviors  using  time- 
constrained  causal  structures.  CLEOPATRA  is  object-oriented  and  compositional,  thus  advocating 
modularity  and  reusability.  CLEOPATRA  is  semantically  sound;  its  objects  can  be  transformed, 
mechanically  and  unambiguously,  into  formal  automata  for  verification  purposes.  Our  experience 
with  CLEOPATRA  confirms  its  suitability  as  a  vehicle  for  the  specification  and  validation  of  many 
embedded  and  time-critical  applications.  In  particular,  we  used  it  to  simulate  and  analyze  asyn¬ 
chronous  digital  circuits,  sensori-motor  behavior  of  autonomous  creatures,  and  intelligent  controllers 
[Best91a,  Best90c,  Best90b].  A  compiler  that  allows  the  execution  of  CLEOPATRA  specifications 
has  been  developed  [Best92],  and  is  available  via  FTP  from  cs  .bu.  edu: /bestavros/cleopatra/. 

CLEOPATRA  is  based  on  the  Time-constrained  Reactive  Automata  (TRA)  formalism  [Best91b, 
Best91c].  Using  the  TRA  formalism,  an  embedded  system  is  viewed  as  a  set  of  asynchronously  inter¬ 
acting  automata  (TRAs),  each  representing  an  autonomous  system  entity.  TRAs  are  reactive  in  that 
they  abide  by  Lynch’s  input  enabling  property  [Lync88b];  they  communicate  by  signaling  events 
on  their  output  channels  and  by  reacting  to  events  signaled  on  their  input  channels.  The  behav¬ 
ior  of  a  TRA  is  governed  by  time-constrained  causal  relationships  between  computation-triggering 
events.  The  TRA  model  is  compositional  and  allows  only  benign  time,  control,  and  computation 
non-determinism.  Using  the  TRA  formalism,  there  is  no  conceptual  distinction  between  a  system 
and  a  property;  both  are  specified  as  formal  objects.  This  reduces  the  verification  process  to  that 
of  establishing  correspondences  -  preservation  and  implementation  -  between  such  objects. 

This  paper  is  organized  as  follows.  In  Section  2,  we  overview  the  TRA  model  and  highligh 
its  suitability  for  the  specification  of  embedded  systems.  In  our  overview,  we  emphasize  the  TRA 
operational  semantics,  which  underlies  the  execution  model  of  CLEOPATRA.  In  Section  3,  we 
describe  the  CLEOPATRA  specification/programming  language.  In  Section  4,  we  present  a  compiler 
that  allows  the  execution  of  CLEOPATRA  specifications.  In  Section  5,  we  conclude  with  current  and 
future  research  directions. 

1 A  C-based  Language  for  the  Lvent-driven  Object-oriented  'Prototyping  of  Asynchronous  Time-constrained  72eactive 
Automata. 
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2  The  TRA  Model 


The  TRA  model  has  evolved  from  our  earlier  work  in  [Best90a]  extending  Lynch’s  IOA  model 
[Lync88b,  Lync88a]  to  suit  embedded  and  time-constrained  computation. 

2.1  Novelties 

Previous  studies  in  modeling  real-time  computing  have  focussed  on  adding  the  notion  of  time  with¬ 
out  regard  to  physical  properties  of  the  modeled  systems.  This  makes  it  possible  to  specify  systems 
that  do  not  abide  by  principles  like  causality  and  spontaneity.  Using  the  TRA  model,  requirements 
that  are  physically  impossible  to  guarantee  are  not  possible  to  express.  This  preventative  approach 
is  likely  to  spare  a  lot  of  time  and  energy  in  the  development  cycle  (specification,  implementation, 
and  verification)  of  responsive  systems. 

The  TRA  model  deals  not  only  with  the  notion  of  time,  but  also  with  the  notion  of  space. 
Events  occur  at  uniquely  identifiable  points  in  time  as  well  as  in  state  space.  Concurrent  events  are 
permitted  only  if  they  affect  disjoint  state  subspaces.  The  payoff  for  this  dual  treatment  of  space 
and  time  is  manifold.  In  particular,  mappings  between  various  levels  of  abstractions  for  compilation 
and  verification  purposes  become  more  robust  as  the  formalism  becomes  more  structured. 

The  TRA  model  does  not  allow  the  specification  of  systems  that  are  not  reactive.  A  system 
is  reactive  if  it  cannot  block  the  occurence  of  events  not  under  its  control.  This  property  is  cru¬ 
cial  for  accurate  and  realistic  modeling  of  embedded  and  real-time  systems.  A  sufficient  condition 
for  reactivity  is  the  input  enabling  property  proposed  in  [Lync88b].  The  TRA  model  is  input  en¬ 
abled.  It  distinguishes  clearly  between  environment-controlled  actions,  which  cannot  be  restricted 
or  constrained,  and  locally-controlled  actions,  which  can  be  scheduled  and  disabled. 

A  non-deterministic  system  is  causal  if  given  two  inputs  that  are  identical  up  to  any  given 
point  in  time,  there  exist  outputs  (for  the  respective  inputs)  that  are  also  identical  up  to  the  same 
point  in  time.  The  TRA  model  enforces  causality  by  requiring  that  any  locally-controlled  actions 
be  produced  only  as  a  result  of  an  earlier  cause.  In  our  work,  a  clear  distinction  is  made  between 
causality  and  dependency.  An  event  occurs  as  a  result  of  exactly  one  earlier  event  but  may  depend 
on  many  others  as  reflected  in  the  state  of  the  system.  This  spares  our  formalism  from  dealing  with 
clairvoyant  and  capricious  behaviors  [Stua91]. 

Spontaneity  is  a  notion  closely  related  to  causality.2  A  system  is  spontaneous  if  its  output 

2Actually  both  spontaneity  and  causality  are  directly  related  to  the  past  and  future  light  cones  of  an  event  in 
space-time  [Hawk88]. 
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actions  at  any  given  point  in  time  t  cannot  depend  on  actions  occuring  at  or  after  time  t.  In 
particular,  if  an  output  occurs  simultaneously  with  (say)  an  input  transition,  the  same  output  could 
have  been  produced  without  the  simultaneous  input  transition  [Sree90].  Simultaneity  is,  thus,  a 
mere  coincidence;  the  output  event  could  have  occured  spontaneously  even  if  the  input  transition 
was  delayed.  The  TRA  model  enforces  spontaneity  by  requiring  that  simultaneously  occuring  events 
be  independent;  time  has  to  necessarily  advance  to  observe  dependencies. 

The  TRA  model  distinguishes  between  two  notions  of  time:  real  and  perceived.  Real  time 
cannot  be  measured  by  any  single  process  in  a  given  system;  it  is  only  observable  by  the  environment. 
Perceived  time,  on  the  other  hand,  can  be  specified  using  uncertain  time  delays.  The  TRA  model, 
therefore,  does  not  provide  for  (or  allow  the  specification  of)  any  global  or  perfect  clocks.  As  a 
consequence,  the  only  measure  of  time  available  for  system  processes  has  to  be  relative  to  imperfect , 
local  clocks.  This  distinction  between  real  time  and  perceived  time  is  important  when  dealing  with 
embedded  applications  where  time  properties  are  stated  with  respect  to  real  time,  but  have  to  be 
preserved  relying  on  perceived  time. 

2.2  Basic  definitions 

We  adopt  a  continuous  model  of  time  similar  to  that  used  in  [Alur90,  Lewi90].  We  represent  any 
point  in  time  by  a  nonnegative  real  /  £  3?.  Time  intervals  are  defined  by  specifying  their  end-points 
which  are  drawn  from  the  set  of  nonnegative  rationals  Q  C  SR.  A  time  interval  is  viewed  as  a 
traditional  set  over  nonnegative  real  numbers.  It  can  be  an  empty  set,  in  which  case  it  is  denoted 
by  e,  it  can  be  a  singleton  set,  in  which  case  it  is  denoted  by  the  [/,/],  /  £  Q,  or  else  it  can  be 
an  infinite  set,  in  which  case  it  is  denoted  by  [/;,/„],  (/;,/„],  [/;,/„),  or  (/;,/„)  -  the  right-closed, 
left-closed,  and  open  time  intervals,  respectively,  where  tptu  £  Q  and  ti  <  tu.  The  set  of  all  such 
infinite  time  intervals  is  denoted  by  V. 

A  real-time  system  is  viewed  as  a  set  of  interacting  mealy  automata  called  TRAs.  TRAs  commu¬ 
nicate  with  each  other  through  channels.  A  channel  is  an  abstraction  for  an  ideal  unidirectional  com¬ 
munication.  The  information  that  a  channel  carries  is  called  a  signal ,  which  consists  of  a  sequence 
of  events.  An  event  underscores  the  occurence  of  an  action  at  a  specific  point  in  time.  An  action  is 
a  value  associated  with  a  channel.  For  example,  let  North,  South,  East,  and  West  be  the  possible 
values  that  can  be  signaled  on  some  channel  MOVE  of  a  given  TRA.  MOVE(East)  is,  therefore,  a  possi¬ 
ble  action  of  the  TRA.  The  instantiation  of  MOVE(East)  at  time  t\  denotes  the  occurence  of  an  event 
(MOVE(East)  :  tf).  The  sequence  of  events  (MOVE(East)  :  /i)(MOVE(North)  :  t2)(M0VE(South)  ;  tf) 
. . .  etc.  constitutes  a  signal.  Signals  are  single  valued;  they  cannot  convey  more  than  one  event 
simultaneously.  That  is,  for  a  signal  (ao  :  to){ai  :  ti)  ■  ■  ■  we  require  that  tj~  <  tk+ 1,  k  >  0. 
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At  any  point  in  time,  a  TRA  is  in  a  given  state.  The  set  of  all  such  possible  states  defines 
the  TRA’s  state  space.  The  state  of  a  TRA  is  visible  and  can  only  be  changed  by  local  computations. 
Computations  (and  thus  state  transitions)  are  triggered  by  actions  and  might  be  required  to  meet 
specific  timing  constraints. 

2.3  TRA  Objects 

Definition  1  A  TRA  object  is  a  sextuple  (E,  op,  II,  0,  A,  T),  where: 
o  E,  the  TRA  signature,  is  the  set  of  all  the  TRA  channels.  It  is  partitioned  into  three  disjoint  sets 
of  input,  output,  and  internal  channels,  denoted  by  Ein,  Eout,  and  Eint,  respectively.  The  set 
consisting  of  both  input  and  output  channels  is  the  set  of  external  channels  (Sex t).  These  are 
the  only  channels  visible  from  outside  the  TRA.  The  set  consisting  of  both  output  and  internal 
channels  is  the  set  of  local  channels  (S \oc).  These  are  the  locally  controlled  channels  of  the  TRA. 
o  do  £  Sin  is  the  start  channel. 

o  II,  the  signaling  range  function,  maps  each  channel  in  E  to  a  possibly  infinite  set  of  values  that 
can  be  signaled  as  actions  on  that  channel.  Action  sets  of  different  channels  are  disjoint.  The 
set  of  all  the  actions  of  a  TRA  is  given  by  11(E).  The  set  of  input,  output,  internal,  external,  and 
local  actions  are  similarly  given  by  II(Ein),  n(Sout),  n(Eint),  n(Eext),  and  II(Eioc),  respectively, 
o  0  is  a  possibly  infinite  set  of  TRA  states.  The  set  0  is  expressed  as  the  cross  product  of  a  finite 
number  of  subspaces  0  =  X  $2  X  . . .  X  &p,  where  p  >  1  is  the  dimension  of  the  state  space, 
o  A  C  0  x  n(s)  X  0  is  a  set  of  possible  computational  steps  of  the  TRA.  TRAs  are  input  enabled 
which  means  that  for  every  n  £  II(Ein),  and  for  every  0  £  0,  there  exists  at  least  one  step 
(d,TT,dr)  £  A,  for  some  O'  £  0.  Thus,  A  defines  a  total  multifunction  A:  9  X  n(S8n)  — ►  9. 
o  T  C  E  X  Sioc  XDX20  is  a  set  of  time- constrained  causal  relationships  (or  simply  time  con¬ 
straints)  of  the  TRA.  A  time  constraint  £  T  is  a  guadruple  (ox,  a[,  Si,  08)  whose  interpretation 
is  that:  if  an  action  is  signaled  at  time  t  £  on  the  channel  Gi,  then  a  corresponding  action 
must  be  fired  on  the  channel  a[  at  time  t' ,  where  t'  —  t  £  hi,  provided  that  the  TRA  does  not  enter 
any  of  the  states  in  08  for  the  open  interval  (t,tr).3  The  channel  £  S  is  called  the  trigger  of 
the  time  constraint,  whereas  a[  £  Eioc  is  called  the  constrained  channel.  08  C  0  defines  the  set 
of  states  that  disable  the  time  constraint;  once  triggered  a  time  constraint  becomes  and  remains 
active  until  satisfied  or  disabled.  A  time  constraint  is  satisfied  by  the  firing  of  an  action  on 
the  channel  within  the  imposed  time  bounds;  it  is  disabled  if  the  TRA  enters  in  one  of  the 
disabling  states  in  08  before  it  is  satisfied.  The  interval  Si  specifies  upper  and  lower  bounds  on 
the  delay  between  the  triggering  and  satisfaction  (or  disabling)  of  the  time  constraint  V{. 

3Notice  that  this  condition  does  not  necessitate  the  existence  of  a  computational  step  (8,  A ,8')  £  A  for  each 
8  £  ©  —  @8,  where  tt'  £  ^(<T,)  and  8'  £  0,  since  the  specification  of  the  TR*\  might  avoid  being  in  8  when  a'  is 
scheduled  to  fire. 
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As  an  example  of  a  TRA  specification,  consider  the  the  up/down  counter  whose  state  diagram 
is  shown  in  Figure  1.  The  counter  accepts  commands  issued  on  the  input  channel  cmd  to  count 
up  or  down  and  signals  the  value  of  the  current  count  (state)  on  the  output  channel  cnt.  The 
counter  starts  its  operation  once  an  action  is  fired  on  the  init  channel.  The  value  of  the  init 
signal  determines  the  starting  state  of  the  counter.  The  counter  is  constrained  to  produce  a  count 
every  at  least  1.9  and  at  most  2.1  units  of  time,  once  it  starts  execution.  Figure  1  shows  the 
TRA-specihcation  of  such  a  counter. 

The  first  three  components  of  a  TRA  sextuple  can  be  viewed  as  defining  an  interface  between 
the  TRA  object  and  its  environment.  In  particular,  to  be  able  to  use  the  counter  of  Figure  1,  it  suffices 
to  know  its  external  signature  Sjn  =  {init,  cmd},  Souti  =  {cnt},  the  identity  of  the  start  channel 
do  =  init,  along  with  the  signaling  range  of  all  the  channels  in  Sextl.  The  last  three  components 
of  a  TRA  sextuple  are  responsible  for  its  behavior.  The  state  space  defines  the  spatial  structure  of 
the  computation.  For  the  counter  of  Figure  1,  this  structure  is  unidimensionally  spanned  by  the 
single  state  variable  0.  The  set  of  computational  steps  defines  the  effect  of  events  on  the  state  of 
the  TRA.  The  set  of  time-constrained  causalities  defines  the  rules  governing  the  scheduling  of  the 
TRA’s  local  events.  For  the  counter  of  Figure  1,  there  are  two  such  rules. 


2.4  Space  and  Time  aspects  of  TRAs 

The  behavior  of  a  TRA  is  generally  lion-deterministic.  Three  sources  of  11011-determinism  can  be 
singled  out.  I11  a  given  state  there  might  be  a  number  of  choices  concerning  the  action  to  be  fired. 
Each  one  of  these  choices  results  in  a  different  computational  step,  and  thus  in  a  different  execution. 
This  gives  rise  to  control  11011-determinism.  The  TRA  timing  constraints  specify  lower  and  upper 
bounds  011  the  delay  between  causes  and  effects,  thus  leaving  the  TRA  with  a  potentially  infinite 
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number  of  choices  concerning  the  exact  delay  to  be  exhibited.  Each  one  of  these  choices  results  in  a 
different  event,  and  thus  in  a  different  execution.  This  gives  rise  to  timing  nondeterminism.  Finally, 
the  computation  associated  with  specific  actions  might  be  non-deterministic.  In  this  case,  firing 
the  same  action  from  the  same  state  might  result  in  different  next  states,  and  thus  in  different 
executions.  This  gives  rise  to  computation  non-determinism.  Considered  separately,  each  one 
of  the  above  forms  of  non-determinism  is  benign.  A  combination  thereof,  however,  deserves  a 
closer  attention.  In  particular,  the  interplay  between  control  non-determinism  and  timing  non¬ 
determinism  is  interesting  because  it  is  related  to  the  notions  of  space  and  time.  Control  non¬ 
determinism  refers  to  uncertainties  about  the  identity  of  the  channel  that  will  be  fired;  it  refers  to 
a  spacial  uncertainty.  As  such,  and  to  abide  by  the  spontaneity  principle,  it  must  reduce  the  range 
of  possible  timing  uncertainty. 

To  illustrate  this  point,  consider  a  TRA,  A,  for  which  two  possible  steps  are:  (9i,TTi,9j)  and 
(9i,'K2,0k),  where  9j  9j~.  Furthermore,  assume  that  A  entered  state  9{  at  time  t  and  that  both 
7Ti  and  7T2  are  scheduled.  Now,  if  the  timing  constraints  for  7Ti  and  7r2  are  specified  such  that  both 
actions  can  fire  on  different  channels  at  some  later  time  T,  then  “what  will  be  the  next  state  of  A. 
Will  it  be  9j  or  9j~  or  neither?”  4  The  issue  here  is  not  whether  the  next  state  should  be  9j  or  9j~. 
Rather,  the  issue  is  whether  or  not  such  a  situation  should  have  been  allowed  in  the  first  place. 

Two  computational  steps  conflict  if  both  of  them  introduce  changes  to  at  least  one  of  the 
subspaces  of  the  TRA’s  state  space.  This  is  formally  defined  below. 

Definition  2  Two  computational  steps  (#;,  7iy,  9[),  (9j,  7Tj,  9()  E  A  conflict  if  and  only  if  for  some 
dimension  k  ofQ,  9i[k\  9[[k\  and  9j[k\  9([k\,  where  1  <  k  <  n. 

It  is  important  to  realize  that  the  conflict  relationship  depends  not  only  on  a  TRA’s  computa¬ 
tional  behavior,  but  also  on  the  structure  of  its  state  space.  In  particular,  two  TRAs  with  isomorphic 
computational  steps  could  have  very  different  conflict  relationships  depending  on  their  state  space 
characterizations.  The  notion  of  conflicting  computational  steps  can  be  easily  extended  to  actions 
and  channels. 

The  conflict  relationship  depicts  computational  dependencies  that  emerge  due  to  sharing 
information  about  state.  For  two  local  actions  to  conflict,  their  respective  channels  must  be  under 
the  control  of  a  single  component  of  the  TRA.  The  transitive  closure  of  the  conflict  relationship, 
therefore,  defines  a  partition  on  the  locally-controlled  channels  of  a  given  TRA. 

Definition  3  Two  local  channels  and  Gj  belongs  to  the  same  component  (class)  if  they  conflict. 

4The  argument  given  here  is  made  assuming  that  both  7Ti  and  7T2  are  locally-controlled  actions.  The  same  argument, 
however,  can  be  made  if  either  7Ti  or  7T2,  or  both  are  input  actions. 
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The  partition  into  classes  of  the  TRA’s  locally-controlled  channels  captures  some  of  the  struc¬ 
ture  of  the  system  the  automaton  is  modeling  or  the  set  of  requirements  it  is  specifying.  In  partic¬ 
ular,  each  class  of  channels  is  intended  to  represent  the  set  of  channels  locally-controlled  by  some 
system  component.  This  partitioning  retains  the  basic  control  structure  of  the  system’s  primitive 
components  and  provides  a  concrete  notion  of  spacial  locality. 

The  actions  on  the  input  channels  of  a  given  TRA  are  not  under  its  control;  they  can  fire  at 
any  time.  To  preserve  the  non-blocking  (input-enabled)  nature  of  the  TRA  model,  it  is,  therefore, 
necessary  to  insure  that  input  actions  on  different  channels  do  not  conflict.  A  TRA  is  improper  if 
at  least  two  of  its  input  channels  conflict,  otherwise  it  is  proper.  For  the  remainder  of  this  paper, 
it  will  be  assumed  that  any  TRA  is  proper  unless  otherwise  stated. 

The  notion  of  system  components  we  are  presenting  here  is  novel  and  entirely  different  from 
that  used  in  untimed  models  to  express  fairness  [Lync88b]  by  requiring  that,  in  an  infinite  execution, 
each  of  the  system’s  components  gets  infinitely  many  chances  to  perform  its  locally-controlled 
actions.  In  timed  systems,  the  major  concern  is  safe  and  not  necessarily  fair  executions  [Schn88]. 
Even  if  required,  fairness  can  be  enforced  by  treating  it  as  a  safety  property;  liveness  properties 
can  be  handled  in  infinite  execution  by  requiring  time  to  grow  unboundedly.5.  This  led  to  the 
abandoning  of  the  idea  of  partitioning  a  system  into  components  in  our  earlier  model  proposed  in 
[Best90a].  Lynch  and  Vaandrager  [Lync91]  followed  suit  in  their  recent  modification  of  the  model 
proposed  in  [Tutt88].  In  the  TRA  model  we  use  system  components  to  represent  what  can  be  termed 
as  spacial  locality.  Different  actions  can  be  signaled  at  the  same  “time”  only  if  they  are  not  signaled 
from  the  same  “place”;  they  can  be  produced  at  the  same  “place”  only  if  they  do  not  occur  at  the 
same  “time”.6 

2.5  TRA  Executions  and  Behaviors 

In  standard  automata  theory,  there  is  no  distinction  between  choosing  a  transition  and  firing  it; 
they  constitute  a  unique,  instantaneous,  and  atomic  activity.  In  the  TRA  model  a  distinction  is  made 
whereby  choosing  (scheduling)  a  transition  and  executing  (committing)  that  transition  are  separate 
activities.  They  are  distinct  in  that  they  are  separated  in  time.  In  fact,  a  scheduled  transition  does 
not  have  to  be  committed;  it  can  be  abandoned  due  to  unforseeable  conditions.  The  distinction 
between  the  two  activities  is  also  pronounced  in  the  way  the  TRA  model  differentiates  between  input 
and  local  events.  Input  events  are  not  under  the  TRA’s  control;  they  cannot  be  blocked  or  delayed. 
Local  events  are  under  the  TRA’s  control;  they  are  time  constrained,  and  could  be  disabled. 

5Such  executions  were  called  admissible  in  [Lync91] 

6This  intuition  is  inspired  from  physical  systems,  where  events  are  characterized  and  distinguishable  by  their 
time-space  coordinates  [Hawk88]. 
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Consider  the  time  constraint  ry  =  (<7;,  a),  Si,  0;)  £  T.  ry  identities  a  time-constrained  causal 
relationship  between  the  events  signaled  on  ay  and  those  signaled  on  a\.  In  particular,  the  occurence 
of  a  triggering  event  on  ay  results  in  an  intention  to  perform  an  action  on  ay-  within  the  time  frame 
imposed  by  Si.  The  commitment  or  abandonment  of  such  an  intention  in  due  time  is  conditional 
on  the  states  assumed  by  the  TRA  from  when  the  intention  is  posted  until  when  it  is  committed 
or  abandoned.  At  any  given  point  in  time,  a  TRA  might  have  several  outstanding  intentions.  In 
particular,  the  occurence  of  a  single  event  might  generate  a  number  of  intentions,  each  dictated  by  a 
different  time  constraint.  Different  outstanding  intentions  are  not  necessarily  imposed  by  different 
time  constraints.  In  particular,  the  repeated  occurence  of  a  triggering  event  might  generate  a 
number  of  outstanding  intentions,  all  of  which  are  posted  by  the  same  time  constraint. 

The  state  of  a  TRA  at  an  arbitrary  point  in  time  is  not  sufficient  to  construct  its  future 
behavior.  In  addition  to  the  state,  the  intervals  of  time  where  scheduled  transitions  might  fire  (due 
to  earlier  triggers)  have  to  be  recorded.  For  a  given  TRA,  we  define  the  intention  vector  I  =  A  to 
be  a  vector  of  r  sets  of  intentions,  where  r  =  |T|.  Each  entry  in  /  is  associated  with  one  of  the 
TRA’s  time  constraints.  In  particular,  if  ry  =  (ay,  ay-,  Si,  08)  £  T  is  one  of  the  TRA’s  time  constraints, 
then  I\vi]  =  {<^'1,  Si2,  ■  ■  ■ ,  S^, . .  .Sim}  denotes  a  set  of  m  time  intervals  during  which  actions  on  the 
channel  ay-  are  intended  to  be  fired  as  a  result  of  earlier  triggers  on  ay.  Each  one  of  the  intervals  in 
A i  can  be  thought  of  as  an  independent  activation  of  the  time  constraint  ry.  An  empty  intentions 
set,  I\vi]  =  <f>,  indicates  the  absence  of  any  activations  of  ry.  The  empty  intention  vector,  /y, 
consists  of  r  such  empty  sets. 

Definition  4  lEe  define  the  status  of  a  TRA  at  any  point  in  time  t  £  to  be  the  tuple  (0,1), 
where  0  and  I  are  the  TRA ’s  state  and  intention  vector  at  time  t,  respectively. 

A  TRA  changes  its  status  only  as  a  response  to  the  occurence  of  an  input  or  an  intended  local 
event.  In  other  words,  the  change  in  a  TRA’s  status  is  necessarily  a  causal  reaction  to  an  input 
event  or  to  an  earlier  triggering  event.  Assume  that  the  status  (0,1)  of  a  TRA  was  entered  at  time 
t  as  a  result  of  an  event  (7 r  :  t),  where  7r  £  Jl(aj),a'-  £  S.  Furthermore,  assume  that  at  time  t' 
(t'  >  t),  an  action  it'  £  II (a))  is  fired,  where  a)  £  S.  As  a  result,  the  TRA  will  assume  a  new  status 
(O',  I').  The  status  (O',  I')  is  called  a  successor  of  the  status  (0,1)  due  to  the  event  (7 r'  :  t’).  Five 
conditions  -  namely,  legality,  spontaneity,  safety,  causality,  and  consistency  -  have  to  be  met  for 
such  a  succession  to  occur. 

Definition  5  Assume  that  the  status  (0,1)  of  a  TRA  was  entered  at  time  t.  Furthermore,  assume 
that  at  a  later  time  t'  >  t,  a  set  of  simultaneous  actions  7Ti  £  n(<7i),7T2  £  II(<72 ),...,  7rm  £  II(<7m) 
were  fired,  where  Gj  £  E,0  <  j  <  m.  As  a  result,  the  TRA  will  assume  a  new  status  (O',  I1),  where 

I'  =  (I  U  Enabled)  “  (^fired  U  ^disabled)’ 
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The  status  (O',  I')  is  called  a  valid  successor  of  the  status  (0,1)  due  to  the  occurence  of  the  set  of 
simultaneous  events  (tti,  7r2, . . . ,  irm  :  t'),  if  and  only  if  the  following  conditions  hold: 


1.  Spontaneity: 

The  channels  G\,  a 2,  ■  ■  ■ ,  <7m  do  not  conflict;  they  belong  to  different  TRA  components. 

2.  Tegality: 

There  exists  some  seguence  of  transitions  (9, 7Ti,  9\),  (0, 7r2, 02),  •  •  •  (0,  irm,  0m)  £  A,  such  that 

0m  =  O'. 

3  Safety: 

For  every  intention  Sik  £  I\vf\,  t"  £  Sik  for  some  t"  >  t' ,  t"  £  where  £  T. 

4-  Causality: 

For  all  Gi  £  Sioc,  the  following  conditions  hold 

a.  If  Gi  Gj  for  all  1  <  j  <  m  then  for  every  vk  =  (Gk,G'k,Sk,Qk)  £  T  for  which  G!k  =  Gi, 
Jfired  iVk\  =  f- 

b.  Otherwise,  let  T i  C  T  be  the  set  of  time  constraint  with  Gi  as  the  constrained  channel,  then 
there  must  exist  exactly  one  time  constraint  vr  £  T i  such  that: 

o  =  {8-rk} ;  where  8rk  £  I\vr\  and  t'  £  8rk,  and 

0  -^firedt^fc]  =  4>,  where  vk  £  T,  and  vk  vr. 

5.  Consistency: 

For  every  time  constraint  vk  =  (Gk,G!k,8k,Qk)  £  T,  the  following  conditions  hold 

a.  If  9'  £  Qk,  then 

O  ^isabledt^fc]  =  and 

O  ^nabledt^fc]  = 

b.  Otherwise 

O  ^disabledb*]  =  <t>>  Cmd 

o  If  Gk  =  Gj  for  some  1  <  j  <  m,  then  /'nabledbfc]  =  {(t'  +  8,  )},  else  /'nabled[^fc]  =  <f>. 

In  the  above  definition,  the  spontaneity  condition  allows  the  occurence  of  simultaneous  events  only  if 
they  do  not  conflict.  This  guarantees  that  the  transition  from  0  to  O'  is  independent  of  the  ordering 
of  concurrent  computational  steps.  The  legality  condition  ensures  that  the  state  change  from  0  to 
O'  is  the  result  of  defined  computational  steps.  The  safety  condition  guarantees  that  no  active  time 
constraint  expires.  In  other  words,  outstanding  intentions  are  either  committed  or  abandoned  in 
due  time.  The  causality  condition  necessitates  that  local  events  be  causal;  they  are  signaled  only 
if  intended  due  to  an  earlier  trigger.  Thus,  the  causality  condition  guarantees  that  there  is  exactly 
one  committed  intention  per  local  event.  In  other  words,  every  local  event  satisfies  exactly  one 
intention.  The  consistency  condition  requires  that  the  intentions  in  /  continue  to  exist  in  I'  unless 
otherwise  dictated  by  the  occurence  of  the  set  of  simultaneous  events  (7Ti  :  t')(-K2  :  t') . . .  (irm  :  t’). 
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We  use  the  notation  (0,1)  A  (g'^p^  to  denote  the  direct  status  succession  from 

(0,1)  to  (O',  I')  due  to  the  bring  of  the  set  of  simultaneous  events  (7Ti  :  t'),  (7^  :  t'),  . . .,  (irm  :  t'). 
Furthermore,  we  use  the  notation  (0,1)  AA  (O',  I')  to  denote  the  extended  status  succession  from 
(0,1)  to  (O',  I')  due  to  a  number  of  direct  status  successions. 

A  TRA  is  said  to  have  reached  a  stable  status  (0,1),  if  all  entries  of  the  intention  vector  are 
empty  (I  =  1^).  A  TRA  remains  in  a  stable  status  until  excited  by  an  input  event.  This  follows 
directly  from  the  causality  requirement  for  a  status  succession. 

To  start  executing,  a  TRA  (£,  op,  II,  0,  A,  T)  is  put  in  a  stable  initial  status  (Oq,Iq),  where 
/0  =  and  Oq  G  0.  The  execution  is  initiated  at  time  to  with  the  firing  of  an  action  7To  on 
the  start  channel  op,  where  7To  G  II(<7o).  An  execution  e  of  a  TRA  is  a  possibly  infinite  string  of 
alternating  statuses  and  events,  which  starts  with  an  initial  status  followed  by  an  initiating  event, 
and  which  contains  an  infinite  number  of  status  successions  (infinite  execution),  or  terminates  in  a 
stable  status  (finite  execution). 

We  follow  an  approach  similar  to  that  adopted  in  [Lync88b]  by  defining  (3  to  be  a  behavior 
of  a  TRA  A,  if  it  consists  of  all  the  external  events  appearing  in  some  execution  e  of  A.  We  denote 
the  set  of  all  the  possible  behaviors  of  a  TRA  A  by  behs(A).  Obviously,  behs(A)  describes  all  the 
possible  interactions  that  the  TRA  A  might  be  engaged  in,  and,  therefore,  constitutes  a  complete 
specification  of  the  system  that  A  models. 

A  TRA  A  is  said  to  implement  another  TRA  B  if  A  does  not  produce  any  behavior  that  B  could 
have  produced.  In  other  words,  all  of  As  behaviors  (the  implementation)  are  possible  behaviors 
of  B  (the  specification).  The  reverse,  however,  is  not  true.  There  might  exist  behaviors  of  B  that 
cannot  be  generated  by  A.  The  notion  of  a  TRA  implementing  another  is  used  mainly  in  verification. 

2.6  TRA  Composition 

A  basic  aspect  of  the  TRA  model  is  its  capability  to  model  a  complex  system  by  operating  on  simpler 
system  components.  In  this  section  we  examine  such  an  operation,  namely  composition.  Other 
operations  (for  example  hiding  and  renaming)  were  presented  in  [Best91c]. 

The  composition  of  a  countable  collection  of  compatible  TRAs,  {Ai  :  i  G  X},  is  a  new  TRA  A  = 
Ao  X  A\  X  . . .  X  Ai  X  . . .  =  ITgj.4;.  The  execution  of  A  involves  the  execution  of  all  its  components 
Aex,  each  starting  from  an  initial  status  and  observing  every  external  event  signaled  by  either  the 
environment  (input)  or  by  any  TRA  in  the  collection  {Ai  :  i  G  X}.  The  compatibility  condition  for 
composition  insures  that,  for  each  channel  in  the  composition,  there  is  at  most  one  writer,  a  finite 
number  of  readers,  and  that  the  signaling  ranges  of  readers  and  writers  are  compatible. 
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The  input  signature  of  the  composed  TRA  consists  of  those  channels  that  are  inputs  to  one  or 
more  of  the  component  TRAs,  and  which  are  not  outputs  of  any  of  the  component  TRAs.  The  output 
signature  of  the  composed  TRA  consists  of  all  the  outputs  of  all  the  component  TRAs.  Similarily,  the 
internal  signature  of  the  composed  TRA  consists  of  all  the  internal  channels  of  all  the  component 
TRAs.  The  start  channel  of  the  composed  TRA  is  the  start  channel  of  one  or  more  of  its  component 
TRAs.7  The  signaling  range  function  of  the  composed  TRA  is  defined  so  as  to  preserve  its  input- 
enabled  property.  In  particular,  the  signaling  range  of  an  input  channel  consists  of  only  those  actions 
that  can  accepted  by  all  readers  of  that  channel.  A  computational  step  of  the  composed  TRA  is 
necessarily  a  step  of  one  of  its  components.  Similarily  the  time-constrained  causal  relationships  of 
the  composed  TRA  are  exactly  those  of  the  component  TRAs. 

In  [Best91c],  the  formal  construction  of  the  sextuple  representation  of  a  composition  is  given. 
Also,  the  relationships  between  the  behaviors  and  spacial  properties  of  the  composed  TRA  and  those 
of  its  constituent  TRAs  are  established.  In  particular,  we  prove  that  the  sets  of  proper,  spontaneous, 
and  causal  TRAs  are  closed  under  composition. 

The  TRA  composition  operation  is  more  general  than  those  reported  in  [Lync88b,  Tutt88, 
Best90a]  in  that  it  allows  the  specification  of  both  parallel  and  sequential  composition.  In  particular, 
the  introduction  of  the  start  channel  permits  the  execution  of  two  TRAs  to  be  concurrent  if  they 
share  the  same  start  channel,  or  to  be  serialized  if  the  start  channel  of  one  (child)  is  an  output  of 
the  other  (parent).  Through  appropriate  composition,  our  model  is  capable  of  representing  all  of 
the  composition  operations  in  [Lyon89]. 


3  CCEOPAT1ZA:  A  TRA-based  Specification  Language 

In  CLEOPATRA,  systems  are  specified  as  interconnections  of  TRA  objects.  Each  TRA  object  has  a 
set  of  state  variables  and  a  set  of  channels.  Time-constrained  causal  relationships  between  events 
occuring  on  the  different  channels,  and  the  computations  (state  transitions)  that  they  trigger,  are 
specified  using  Time- constrained  Event-driven  Transactions  (TETs).  The  behavior  of  a  TRA  object 
is  described  using  TETs.  TRA  objects  can  be  composed  together  to  specify  more  complex  TRAs. 

The  correspondence  between  CLEOPATRA  and  the  TRA  formalism  is  straightforward.  Every 
object  in  CLEOPATRA  corresponds  to  a  TRA  sextuple.  In  [Best91c],  the  construction  of  a  TRA 
sextuple,  given  a  CLEOPATRA  object,  is  detailed. 

7  Without  loss  of  generality,  we  assume  that  TR*\  to  be  Ao- 
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3.1  Classes  and  Objects 

A  TRA  object  specification  in  CLEOPATRA  consists  of  two  components:  a  header  and  a  body.  An 
object’s  header  specifies  its  name,  the  parameters  needed  for  its  instantiation,  and  its  signature.  An 
object’s  body  specifies  its  behavior.  In  its  simplest  form,  this  entails  the  specification  of  the  TRA’s 
state  space  and  its  potentially  time-constrained  set  of  reactions  to  the  different  events  visible  to  it. 
More  complex  behaviors  include  (among  others)  the  specification  of:  internal  channels,  initialization 
code,  and  interconnection  of  local  (composed)  objects.  Figure  2  shows  a  BNF-like  description  of  a 
TRA  object  in  CLEOPATRA. 

In  CLEOPATRA,  TRAs  are  defined  in  classes.  For  example,  Figure  3  shows  the  CLEOPATRA 
specification  of  the  class  of  integrators  that  use  trapezoidal  approximation. 


<tra-object>  :=  <tra-header>  ‘{’  <tra-body> 

<tra-header>  :=  ‘TRA-class’  <tra-name>  {‘(’  <tra-params-spec>  ')’}  <signature> 
<tra-params-spec>  :=  {<type>  <param-id>  <tra-params-spec>}} 

<signature>  :=  {<ch-list-spec>}  '->’  {<ch-list-spec>} 

<ch-list-spec>  :=  <ch-id>  (  <type>  )  <ch-list-spec>} 

<type>  :=  ‘ int ’  I  ‘double’  I  ‘bool’  I  ... 

<tra-body>  :=  {<declarations>}  {<init>}  {<transactions>} 

<declarations>  :=  {<state>}  {<internal>}  {<included>} 

<state>  :=  ‘state:’  <state-var-def > 

<state-var-def >  :=  <type>  <var-list-def >  {<statevar-def >} 

<var-list-def >  :=  <var-id>  {'=’  <constant-exp>}  <var-list-def >} 

<internal>  :=  ‘internal:’  <signature> 

<included>  :=  ‘included:’  <included-obj ects> 

<included-obj ects>  :=  <tra- instantiation  {<included-obj ects>} 

<tra- instantiation  :=  <tra-name>  {‘(’  <actual-param-list>  ')’}  <ext-binding> 
<actual-param-list>  :=  <constant-exp>  <actual-param-list>} 

<ext-binding>  :=  {<ch-list>}  '->’  {<ch-list>} 

<ch-list>  :=  <ch-id>  <ch-list>} 

<init>  :=  <code> 

<transactions>  :=  {<xact>  {<transactions>}} 

<xact>  :=  <xact-header>  ':’  <xact-body> 

<xact-header>  :=  {<trigger-list>}  '->’  <out-sig-spec> 

<trigger-list>  :=  <in-sig-spec>  <trigger-list>} 

<in-sig-spec>  :=  <ch-id>  ‘ ( ’  {<var-id>}  ')’ 

<out-sig-spec>  :=  <ch-id>  ‘ ( ’  {<exp>}  ')’ 

<xact-body>  :=  <act>  I  ‘{’  <acts> 

<acts>  :=  <act>  {<acts>} 

<act>  :=  <computation>  I  {<condf rame>}  <fire-acts>  I  {<timef rame>}  <fire-acts> 
<computation>  :=  ‘commit’  ‘{’  <code>  I  ‘do’  ‘{’  <code> 

<condframe>  :=  ‘unless’  ‘(’<cond>‘)’  I  ‘while’  ‘(’<cond>‘)’ 

<timeframe>  :=  <closed-timef rame>  I  <open-timef rame> 

<closed-timef rame>  :=  ‘within’  ‘ [ ’ <constant-exp>  ‘  ~ ’<constant-exp>‘] ’ 
<open-timef rame>  :=  ‘before’  <constant-exp>  I  ‘after’  <constant-exp> 


Figure  2:  Partial  Syntax  of  a  TRA  specification  in  CCSOPATRA 
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TRA-class  integrate (double  TICK,  TICK_ERROR) 
in(double)  ->  out (double) 

{ 

state : 

double  x0=0,  xl=0,  y=0; 
act : 

in(xl)  ->  : 

> 

init(),out()  ->  out(y): 

within  [TICK-TICK_ERROR~TICK+TICK_ERROR] 
commit  {  y  =  y+TICK*(xO+xl)/2;  xO  =  xl;  } 

> 


Figure  3:  Specification  of  the  class  of  integrators  that  use  the  trapezoidal  rule. 

TRA  classes  are  parametrized.  For  instance,  the  specification  of  integrate  given  in  Figure  4 
includes  the  parameters  TICK,  and  TICK_ERROR,  which  have  to  be  specified  before  instantiating  an 
object  from  that  class. 

The  header  of  a  TRA  class  determines  its  external  signature  and  signaling  range  function.  For 
example,  any  TRA  from  the  class  integrate  specified  in  Figure  3  has  a  signature  consisting  of  an 
input  channel  in  and  an  output  channel  out.  Both  in  and  out  carry  actions  whose  values  are 
drawn  from  the  set  of  reals.  In  CCEOTATRA,  the  start  channel  of  any  given  TRA-class  is  called  init. 
Start  channels  do  not  have  to  be  explicitly  included  in  the  header  of  a  TRA-class.  For  example, 
in  the  definition  of  the  integrate  TRA-class  given  in  Figure  3,  there  is  no  mention  of  any  init 
channels  in  the  external  signature  specified  in  the  header,  yet,  init  is  used  later  in  the  body  of 
integrate. 

The  body  of  a  TRA  class  determines  the  behavior  of  objects  from  that  class.  Such  a  behavior 
can  be  either  basic  or  composite.  The  description  of  a  basic  behavior  involves  the  specification  of  a 
state  space  in  the  state:  section,  the  specification  of  an  initialization  of  that  space  in  the  init: 
section,  and  the  specification  of  a  set  of  Time-constrained  Event-driven  Transactions  in  the  act : 
section.  The  behavior  of  an  object  belonging  to  the  TRA-class  integrate  shown  in  Figure  3  is  an 
example  of  a  basic  behavior.  Composite  behaviors,  on  the  other  hand,  are  specified  by  composing 
previously  defined,  simpler  TRA-classes  together  in  the  include :  section.  For  example,  in  Figure  4, 
the  class  ramp  is  defined  by  composing  the  integrate  and  constant8  classes  together. 

8The  behavior  of  an  object  from  the  constant  class  is  to  signal  the  value  VAL  on  its  only  output  channel  out  every 
TICK  ±  TICK_ERROR  units  of  time. 
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TRA-class  ramp()  ->  y (double) 

{ 

internal : 

x (double)  ->  ; 
include : 

constant  ->  x()  ; 
integrate  x()  ->  y()  ; 

> 


Figure  4;  CLEOPATRA  specification  of  a  ramp  generator. 


3.2  Time-constrained  Event-driven  Transaction 

In  CCICJPATRA,  the  time-constrained  causal  relationships  between  events  occuring  on  the  different 
channels  of  a  TRA-class,  and  the  computations  (state  transitions)  that  they  trigger,  are  specified 
using  Time-constrained  Event-driven  Transactions  (TET)  A  TET  describes  the  reaction  of  a  TRA 
to  a  subset  of  events.  Such  a  reaction  might  involve  responding  to  triggers  and/or  firing  action(s). 
Figure  5  explains  the  relation  between  the  triggering  and  firing  of  actions  using  TETs. 


within[Tmin~Tmax] 


Figure  5:  Time-constrained  Event-driven  Transaction  (TET). 

The  description  of  a  TET  consists  of  two  parts:  a  header  and  a  body.  The  header  of  a  TET 
specifies  a  set  of  triggering  channels  (trigger  section)  and  a  controlled  channel  (fire  section).  The 
trigger  section  specifies  the  effect  of  the  triggering  actions  on  the  state  of  the  TRA.  In  particular, 
it  specifies  at  most  one  state  variable  (per  triggering  channel)  where  the  value  of  a  trigger  on  that 
channel  is  to  be  recorded.  A  TET  with  no  triggering  section  is  triggered  every  time  an  action  is 
signaled  on  any  channel  of  the  TRA.  In  other  words,  its  trigger  set  is  considered  to  be  the  same 
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as  the  TRA’s  signature.  The  fire  section  specifies  the  action  vaiue  to  be  signaied  on  the  controiied 
channei  as  a  resuit  of  hring  the  TET.  This  vaiue  can  be  any  expression  on  the  state  of  the  TRA.  An 
absent  expression  means  that  a  random  vaiue  from  the  signaling  range  of  the  controlled  channel  is 
to  be  signaled.  The  body  of  a  TET  describes  possible  reactions  to  the  TET  triggers.  Each  reaction 
is  associated  with  a  disabling  condition,  a  time  constraint,  and  a  state  transformation  schema. 

For  example,  the  first  TET  of  the  integrate  class  shown  in  Figure  3  is  an  example  of  a 
transaction  with  only  a  trigger  section.  Every  time  an  action  is  signaled  on  the  input  channel  in, 
its  value  is  stored  in  the  state  variable  xl,  thus,  resulting  in  a  potential  input  transition.  The  second 
TET  of  the  integrate  class,  on  the  other  hand,  is  an  example  of  a  transaction  with  both  a  trigger 
section  and  a  fire  section.  In  particular,  every  time  an  action  is  signaled  on  one  of  the  triggering 
channels  (init  or  out)  an  output  action  is  fired  on  out  after  a  delay  of  TICK  ±  TICK_ERROR  units 
of  time  elapses. 

Each  reaction  in  the  body  of  a  TET  is  associated  with  three  pieces  of  information:  A  disabling 
condition,  a  time  constraint,  and  a  state  transformation  schema. 

The  disabling  condition  (unless  clause)  is  a  boolean  expression  (predicate)  on  the  state  of  the 
TRA.9  In  order  to  be  committed,  a  reaction’s  disabling  condition  has  to  remain  false  from  when 
the  reaction  is  triggered  until  it  commits.  In  other  words,  an  intended  reaction  is  aborted  if  at  any 
point  in  time  after  its  triggering  (scheduling),  the  disabling  condition  becomes  true.  The  absence 
of  a  disabling  condition  in  a  reaction  implies  that,  once  scheduled,  it  cannot  be  disabled. 

The  time  constraint  (within  clause),  determines  a  lower  and  upper  bound  for  the  real-time 
delay  between  scheduling  a  reaction  and  committing  it.  Only  constant  expressions  are  allowed  to 
be  used  in  the  specification  of  time  bounds.  Open,  closed,  and  semi-closed  time  intervals  can  be 
used  provided  they  specify  an  interval  of  time  from  the  set  V.w  The  absence  of  a  time  constraint 
from  a  TET  specification  implies  that  the  causal  relationship  between  the  trigger  and  its  effect  is 
unconstrained  in  time.  A  lower  bound  of  0  and  an  upper  bound  of  oo  is  assumed  in  such  cases. 

The  state  transformation  schema  (commit  clause)  specifies  a  method  for  computing  the  next 
state  of  the  TRA  once  a  reaction  is  committed.  We  adopt  a  C-like  syntax  for  the  specification  of 
TET  methods.  Statements  in  a  TET  method  are  executed  sequentially.  The  state  transition  caused 
by  the  execution  of  a  TET  method  is  assumed  to  be  atomic  and  instantaneous.  An  absent  commit 
clause  implies  that  committing  the  reaction  does  not  cause  any  state  changes. 

9No  side  effects  are  permitted  in  the  evaluation  of  this  condition. 

10Current  CC£OVATTLA  processors  accept  only  dense  intervals  of  three  forms:  (0,T„),  (Tpoo),  or  [Ti,Tu],  where 
Tu  >  Ti  >  0.  These  are  introduced  using  the  before,  after,  and  within  clauses,  respectively. 
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3.3  An  Example 

Figure  6  shows  the  specification  of  a  finite  FIFO  element  in  CLEOPATRA.  Values  fed  into  the  FIFO 
element  are  delayed  for  some  amount  of  time  before  being  produced  as  outputs. 


TRA-class  fifo(int  I) 

in(float)  ->  out(float),  overflow!),  ack() 

{ 

state : 
float  y [I] ; 
int  i ,  j  ; 
bool  f ; 
act : 

init ( )  ->  ack( ) : 
before  DLY_MII 

commit  {i=0;j=0;f=  FALSE;  } 
in(y [i] )  ->  ack() : 
before  DLY_MII 

commit  {  i  =  (i+l)1/,!  ;  if  (i==j)  f  =  TRUE  ;  } 
in()  ->  out (y [j] ) : 
unless  (f) 

within  [DLY_MII~DLY_MAX] 
commit  {  j  =  (j  +  l)1/,!  ;  } 
in()  ->  overflow!): 
unless  ( ! f ) 

within  [DLY_MII~DLY_MAX] 


Figure  6:  CCSOPATRA  specification  of  a  finite  FIFO  delay  element. 


The  header  of  the  f  ifo  TRA-class  identifies  the  channel  in  as  input,  and  the  channels  out, 
ack  and  overflow  as  outputs.  Although  not  explicitly  specified  as  such,  the  channel  init  (the  start 
channel)  is  assumed  to  be  an  input  channel.  The  signaling  range  for  channels  in  and  out  is  the  set 
of  floating  point  numbers,  whereas  the  signaling  range  for  channels  ack  and  overflow  consists  of 
only  one  value.  The  body  of  the  fifo  TRA-class  contains  two  sections.  In  the  state:  section,  the 
state  space  of  a  fifo  object  is  described  by  four  state  variables:  a  vector  y[]  of  N  floating  point 
values,  two  integer  values  i  and  j,  and  a  boolean  value  f.  In  the  act:  section,  the  behavior  of  a 
fifo  object  is  described  by  four  TETs,  each  of  which  underscores  a  causal  relationship  between 
the  events  triggering  its  execution  and  those  resulting  from  its  execution.11 

The  first  TET  in  the  body  of  the  FIFO  establishes  a  causal  relationship  between  events 
signaled  on  init  and  and  those  signaled  on  ack.  In  particular,  firing  an  action  on  init  (the 
trigger)  causes  the  firing  of  an  action  on  ack  (the  result)  after  a  a  delay  of  at  most  DLY_MIN.  The 

11In  other  words,  between  input  and  output  transitions. 
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second  TET  establishes  a  similar  causal  relationship  between  events  signaled  on  in  and  ack.  The 
third  TET  establishes  a  causal  relationship  between  events  signaled  on  in  and  out.  In  particular, 
firing  an  action  action  on  in  causes  the  firing  of  an  action  on  out  after  a  delay  of  at  least  DLY_MII 
and  at  most  DLY_MAX  elapses,  provided  that  the  FIFO  did  not  overflow  as  of  the  last  initialization. 
The  causal  relationship  that  the  fourth  TET  establishes  can  be  explained  similarly. 

Each  TET  in  a  TRA-class  specifies  up  to  two  possible  state  transitions.  Consider,  for  example, 
the  second  TET  in  the  FIFO  specification  given  in  Figure  6.  In  response  to  a  trigger  on  in,  the 
value  of  the  triggering  signal  is  stored  in  the  state  variable  y  [i] ,  thus  resulting  in  a  possible  state 
change.  Notice  that  this  transition  cannot  be  blocked  or  delayed;  it  is  an  input  transition.  The 
second  state  transition,  an  output  transition ,  occurs  with  the  firing  of  an  action  on  ack,  resulting 
in  the  adjustment  of  the  values  of  the  state  variables  i  and  f .  Notice  that  the  value  of  the  action 
signaled  on  a  local  (output  or  internal)  channel  does  not  reflect  the  state  change  associated  with  it. 
For  instance,  in  the  fourth  TET  of  Figure  6,  the  value  signaled  on  the  out  channel,  namely  y[j]  , 
does  not  reflect  the  changes  introduced  in  the  commit  clause,  namely  advancing  the  pointer  j . 

3.4  Case  and  Point! 

It  is  important  to  realize  that  f  ifo  objects  will  behave  as  expected  only  if  inputs  from  the  environ¬ 
ment  meet  certain  conditions.  In  particular,  the  value  of  the  index  i  is  not  incremented  as  a  result 
of  an  input  on  the  channel  in  until  at  least  DLY_MIN  units  of  time  elapse  following  the  signaling  of 
that  input.  It  follows  that  an  erroneous  behavior  will  result  if  two  or  more  events  are  signaled  on 
the  channel  in  in  a  duration  of  time  shorter  than  DLY_MIN.  To  avoid  such  a  malignant  behavior, 
the  environment  must  wait  for  an  acknowledgment  ack()12  or  else,  must  wait  for  at  least  DLY_MIN 
before  signaling  a  new  input.  Such  correctness  (safety)  conditions  can  be  verified  using  TRA-based 
verification  techniques  [Best91c]. 

We  argue  that  any  finite  implementation  of  a  fifo  object  (discrete-event  delay  element) 
must  have  a  finite  capacity,  which  must  not  be  exceeded  for  a  correct  behavior.  Using  CC£(7PATRA, 
it  is  impossible  to  specify  a  fifo  class  that  behaves  correctly  independent  of  its  environment’s 
behavior.  This  is  a  direct  result  of  our  abidance  by  the  causality  and  spontaneity  principles,  which 
are  preserved  by  the  TRA  model.  As  we  mentioned  at  the  outset  of  this  paper,  it  is  our  thesis  that 
preventing  the  specification  of  physically-impossible  objects  is  desired.  At  the  least  is  spares  system 
developers  from  trying  to  implement  the  impossible. 

12An  ackO  event  is  signaled  when  the  previous  input  has  been  processed. 
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4  CCSOPAT1ZA:  A  Simulation  Language 


We  have  developed  a  compiler  that  transforms  CLEOPATRA  specifications  into  an  event-driven  sim¬ 
ulator  for  validation  purposes.  We  have  used  the  CLEOPATRA  compiler  to  simulate  a  variety  of 
systems.  In  particular,  we  used  it  extensively  to  specify  and  analyze  sensori-motor  robotics  appli¬ 
cations  [BestOOc]  and  to  simulate  complex  behaviors  of  autonomous  creatures  [BestOla].  Figure  7 
shows  the  different  stages  involved  in  the  compilation  and  execution  of  specifications  written  in 

Cleopatra. 


System -defined 
TRA-classes,  types, 
debugging  tools,  ...  etc. 


Specification  Compilation  Simulation 


Figure  7:  Compilation  and  simulation  of  CCfOPATTZA  specifications. 

At  the  heart  of  this  process  is  a  one-pass  preprocessor,  written  in  C,  which  parses  user- 
defined  CLEOPATRA  specifications,  augmented  with  system-defined  TRA  classes,13  and  generates  an 

lo System-defined  TR*\  classes  are  mainly  for  i/o  and  debugging  purposes. 
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Figure  8:  A  stand-alone  process  control  system. 


#include  "sysTRA . cleo" 

TRA-class  worldQ 

y(double)  ->  x(double),  z(double) 

#def ine  TAU  1 

{ 

#def ine  DLY  5 

include : 

user(300)  ->  x()  ; 
plant (1.5)  y ( )  ->  z()  ; 

TRA-class  user(double  EPOCH) 

->  x (double) 

> 

{ 

TRA-class  control () 

act : 

x(double),  z(double)  ->  y(double) 

init(),x()  ->  x(random(0 , 1) ) : 

{ 

within  [0 . 8*EP0CH~ 1 . 2*EP0CH] 

state : 

> 

> 

double  s  =  0,  f  =  0; 

act : 

TRA-class  plant (double  GAIN) 

x ( s ) ,  z(f )  ->  y (s-f ) : 

y(double)  ->  z(double) 
s 

within  [0 . 95*TAU~ 1 . 05*TAU] 

state : 

double  drive  =  0,  val  =  0  ; 

> 

> 

TRA-class  main()  -> 

act : 

{ 

y(drive)  ->  : 

> 

internal : 

->  x(double) ,y (double) ,z (double) 

init(),  z()  ->  z(val): 

include : 

within  [0 . 9*DLY~ 1 . 1*DLY] 

world  y()  ->  x(),  z()  ; 

commit  { 

control  x(),  z()  ->  y()  ; 

val  =  val  +  GAII*drive  ; 

f monitor ("x.dat")  x()  ->  ; 

> 

f monitor ("z.dat")  z()  ->  ; 

> 

> 

Figure  9:  The  main  TRA  -class. 
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equivalent  C  simulator.  This  C  simulator  consists  of  three  components.  The  first  is  a  header  (.h) 
hie,  which  includes  type  definitions  for  the  state  space  of  the  various  TRA  classes  in  the  specification. 
The  second  is  a  schema  (.s)  hie,  which  includes  dehnitions  for  the  state  transition  functions  of  the 
various  TETs.  The  third  is  the  code  ( .  c)  hie,  which  includes  the  simulator  initialization  and  control 
structure  along  with  the  instantiation  code  for  the  various  TRA  classes,  including  main.  The  hnal 
step  of  this  process  involves  the  invocation  of  the  C  compiler  to  produce  an  executable  simulator. 
Figure  10  illustrates  a  typical  session,  in  which  the  CLEOPATRA  compiler  ccleo  is  invoked  to  process 
the  hie  process-ctrl .  cleo  containing  the  specihcation  of  the  stand-alone  process  control  system 
shown  in  Figures  8  and  9. 

In  CLEOPATRA,  any  TRA-class  with  no  input  channels  represents  a  stand-alone  (closed)  system 
whose  behavior  is  independent  from  the  outside  world;  it  is  a  world  of  its  own.  One  such  TRA-class, 
namely  main,  is  singled  out  by  CLEOPATRA  to  represent  the  entire  system  being  specihed.  For 
embedded  systems,  a  typical  main  TRA-class  will  simply  be  the  composition  of  a  programmed 
system,  representing  the  control  system,  and  an  external  interface,  representing  the  environment. 
For  example,  the  main  TRA-class  shown  in  Figure  9  represents  the  CLEOPATRA  specihcation  of 
the  closed  process  control  system  shown  in  Figure  8.  The  execution  of  a  CLEOPATRA  stand-alone 
system  is  started  by  instantiating  an  object  from  the  TRA-class  main  at  time14  0  and,  thereafter, 
committing  only  the  legal  transitions  dictated  by  the  system  specihcation  and  the  semantics  of  the 
TRA  model.  Figure  11  shows  the  values  signaled  on  the  x  and  z  channels  over  time. 

A  library  of  system-dehned  TRA-classes  is  available  for  debugging  and  performing  I/O  in 
CLEOPATRA.  For  example,  in  the  specihcation  of  the  TRA-class  main  given  in  Figure  9,  the  TRA-class 
fmonitor  is  used  to  record  the  action  values  signaled  on  the  x  and  z  channels  in  hies  x.dat  and 
z.dat  respectively.  System-dehned  TRA-classes  are  themselves  specihed  in  CLEOPATRA.  They  are 
different  from  user-dehned  TRA-classes  in  that  they  have  access  to  global  information  known  only 
to  the  simulator.  For  instance,  fmonitor  objects  have  access  to  the  simulator’s  perfect  clock,  _clk, 
whereas  user-dehned  TRA-classes  have  to  maintain  their  own  locally  perceived  clocks,  if  needed. 

C  functions  can  be  called  from  within  a  CLEOPATRA  specihcation.  To  maintain  the  semantics 
of  the  TRA  formalism,  however,  only  functions  with  no  side  effects  should  be  used.  In  other  words, 
C  function  should  be  restricted  to  act  as  pure  operations  on  the  state  variables  of  an  object.  It 
should  not  reach  beyond  the  boundaries  of  the  state  space  of  that  object.  Also,  it  should  not  alter 
the  structure  of  the  state  space  of  the  object  in  any  way.  An  example  of  the  use  of  a  C-function 
is  illustrated  in  the  description  of  the  user  TRA-class  of  Figure  9  where  the  function  random! )  is 
called  periodically  to  generate  a  random  set  value. 

14The  start  time  of  the  simulation  can  be  explicitly  specified. 
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'/,  ccleo  process-ctrl 
TRA-class  fmonitor (string  FILENAME) 
init(unit),  signal (double)  ->  ; 

TRA-class  user(double  EPOCH) 
init(unit)  ->  x (double)  ; 

TRA-class  plant (double  GAIN) 

init(unit),  y(double)  ->  z(double)  ; 

TRA-class  worldQ 

init(unit),  y(double)  ->  x(double),  z(double)  ; 

TRA-class  control () 

init(unit),  x(double),  z(double)  ->  y(double)  ; 

TRA-class  main() 

init(unit)  ->  ‘z(double)’,  ‘y(double)’,  ‘x(double)’  ; 

Cleopatra  preprocessing  completed. 

C  compilation  completed. 

"/,  process-ctrl 

CPU  time  =  1366612  usee  #  of  events  =  5486  SEPS  =  4014.3069 


Figure  10:  A  typical  CCSOPATTZA  compilation  and  execution  session. 


Set  Value  (X)  and  System  Response  (Z)  Signals 

Value 


Signal  X 
Signal  Z 


Time 


Figure  11:  Simulated  behavior  of  an  underdamped  process  control  system. 
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Most  of  the  C  preprocessor  utilities  are  available  in  CLEOPATRA.  This  includes  simple  and 
parameterized  macro  definition  and  invocation,  constant  definition,  and  nested  hie  inclusion.15 
For  example,  in  the  CLEOPATRA  specification  of  the  stand-alone  process  control  system  shown  in 
Figure  9,  system-defined  TRA  classes  are  included  using  the  #include  directive,  and  constants  are 
defined  using  the  #define  directive. 

The  simulator  has  proven  to  be  quite  efficient.  This  is  due  primarily  to  the  causal  and 
compositional  nature  of  the  TRA  model,  which  tend  to  localize  the  computation  triggered  by  the 
occurrence  of  an  event  within  the  boundaries  of  few  TETs.  The  number  of  simulated  events  per 
second  (seps)  depends  on  a  number  of  factors:  the  average  channel  fan-out,  the  average  number  of 
TETs  per  TRA,  and  the  complexity  of  the  event-driven  computation.  It  does  not  depend,  however, 
on  the  size  of  the  state  space  or  on  the  amount  of  TRA  nesting.  For  an  application  with  a  fan-out 
of  1  and  an  average  of  2.4  TETs  per  TRA,  and  an  0(1)  event-driven  computational  complexity,  the 
compiled  CCECJPATRA  specifications  executed  at  a  rate  of  almost  19,500  seps.16  The  performance 
of  a  simulator  for  the  same  application  hand  coded  directly  in  C  performed  only  slightly  better. 
Namely,  it  executed  at  a  rate  of  almost  20,000  seps.  The  performance  of  the  simulator  degrades 
considerably  when  extensive  I/O  and  tracing  operations  are  performed.17 


5  Conclusion 

Predictability  can  be  enhanced  in  a  variety  of  ways.  It  can  be  enhanced  by  restricting  expressive¬ 
ness  as  was  done  in  Real-Time  Euclid  [Klig86],  by  sacrificing  accuracy  as  was  done  in  the  Flex 
system  [Chun90],  or  by  abstracting  segmented  resources  as  was  done  in  the  Spring  kernel  [Stan89]. 
The  TRA- development  methodology  we  are  advocating  here  introduces  one  more  way  of  improving 
predictability,  that  of  allowing  only  physically- sound  specifications.  Pursuing  the  ideas  presented  in 
this  paper  will  undoubtedly  provide  us  with  one  more  handle  in  our  persistent  quest  for  predictable 
systems.  An  interesting  question  to  be  addressed  in  the  future  would  be  whether  this  and  other 
handles  can  be  combined  in  any  useful  way  to  guarantee  predictability. 

Our  experience  with  the  TRA  development  methodology  in  the  design,  simulation,  and  anal¬ 
ysis  of  asynchronous  digital  circuits,  sensori-motor  autonomous  systems,  and  intelligent  controllers 
confirms  its  suitability  for  the  specification,  verification,  and  validation  of  many  embedded  and  time- 
critical  applications.  Its  usefulness  in  the  implementation  of  such  systems,  although  promising,  is 

15 Current  CCEOVATRA  processors  do  not  admit  conditional  compilation. 

16A11  simulations  were  performed  on  a  SPARCstation  SLC™ workstation. 

17This  is  the  case  in  the  simulation  shown  in  Figure  10,  where  an  almost  5-fold  decrease  in  efficiency  can  be 
attributed  to  the  use  of  the  fmonitor  TR4-class. 


24 


yet  to  be  established.  An  fruitful  direction  for  future  research  would  be  to  automate  the  process 
of  transforming  TRA-based  physically- sound  time-critical  specifications  into  provably- correct  imple¬ 
mentations  given  appropriate  resources.  Such  research  will  have  two  complementary  -  experimental 
and  theoretical  -  components.  The  experimental  component  would  involve  the  development  of  a 
compiler  to  transform  CLEOPATRA  specifications  into  predictable  real-time  programs,  given  a  ded¬ 
icated  computing  platform.  The  theoretical  component  would  aim  at  devising  efficient  verification 
algorithms  that  can  be  automated  and  incorporated  in  the  CLEOPATRA  compiler. 
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